Deployment of maintenance packages to computing platforms often require downtime of such platforms. At the beginning of downtime, a backup is created and this backup serves as a fallback option, in case the upgrade fails. Advancements in technology have enabled for reduced, and in some cases, zero downtime upgrades. With such arrangements, upgrades run in parallel to a production system within the same database for the complete duration of the upgrade. The procedure creates clones of the tables, which are changed by the upgrade and runs database triggers to replicate data from production to the upgrade copy of the tables. With the maintenance procedure running in parallel with the production system in the same database, the upgrade can no longer be revoked by restoring a backup.
A restore of a backup is usually done as a point-in-time recovery: the full backup is restored, then the re-do-logs of the changes done to the system between the point in time of the full backup and the point in time, the administrator wants to restore are rolled forward. Such restores can only be run for the complete database.
During the upgrade procedure, not only is database content deployed, but software modules are also being executed (after-import-methods). For these software modules, it can be rather complicated to automatically determine, which database tables are read and written. The upgrade tool initiating the upgrade procedure can be provided with metadata about the database access for each after-import-method and/or accesses can be provided manually.
If there are errors in the metadata or the computation of any corresponding categories, the upgrade procedure can endanger the consistency of the production system during the course of the upgrade. For example, the upgrade can write data to a table that is shared. The production system can then read this data and this data may corrupt the business processes (i.e., the content of the target software package is written to the start release software and this mixture is not guaranteed to properly work). In addition, the database content computed as part of the upgrade procedure can in some cases become corrupted (i.e., data which is read by the upgrade procedure is not correctly locked against changes by the production system).